Course Registration System Software Architecture Document
Version 1.0 Revision History
Table of Contents 2. References 3. Architectural Representation 4. Architectural Goals and Constraints 6. Logical View 7. Process View 10. Quality
Software Architecture Document This Software Architecture Document provides an architectural overview of the C-Registration System. The C-Registration System is being developed by Wylie College to support online course registration. This Document has been generated directly from the C-Registration Analysis & Design Model implemented in Rose. The majority of the sections have been extracted from the Rose Model using SoDA and the Software Architecture Document template.
This document presents the architectural as a series of views; use case view, process view, deployment view, and implementation view. These views are presented as Rose Models and use the Unified Modeling Language (UML).
A description of the use-case view of the software architecture. The Use Case View is important input to the selection of the set of scenarios and/or use cases that are the focus of an iteration. It describes the set of scenarios and/or use cases that represent some significant, central functionality. It also describes the set of scenarios and/or use cases that have a substantial architectural coverage (that exercise many architectural elements) or that stress or illustrate a specific, delicate point of the architecture. The C-Registration use cases are: - Login - Register for Courses - Maintain Student Information - Maintain Professor Information - Select Courses to Teach - Submit Grades - View Report Card - Close Registration. These use cases are initiated by the student, professor, or the registrar actors. In addition, interaction with external actors; Course Catalog and Billing System occur. Diagram Name: Architecturally Significant Use-Cases
Brief Description:This use case allows a Registrar to close the registration process. Course offerings that do not have enough students are cancelled. Course offerings must have a minimum of three students in them. The billing system is notified for each student in each course offering that is not cancelled, so the student can be billed for the course offering. The main actor of this use case is the Registrar. The Billing System is an actor involved within this use case.
Brief Description:This use case describes how a user logs into the Course Registration System. The actors starting this use case are Student, Professor, and Registrar.
Brief Description:This use case allows the registrar to maintain professor information in the registration system. This includes adding, modifying, and deleting professors from the system. The actor of this use case is the Registrar.
Brief Description:This use case allows a professor to select the course offerings (date- and time- specific courses will be given) from the course catalog for the courses that he/she is eligible for and wishes to teach in the upcoming semester. The actor starting this use case is the Professor. The Course Catalog System is an actor within the use case.
Brief Description:This use case allows a student to register for courses in the current semester. The student can also modify or delete course selections if changes are made within the add/drop period at the beginning of the semester. The Billing System is notified of all registration updates. The Course Catalog provides a list of all the course offerings for the current semester. The main actor of this use case is the student. The Course Catalog System is an actor within the use case.
Brief Description:This use case allows a student to view his/her report card for the previously completed semester. The student is the actor of this use case.
Brief Description:This use case allows a professor to submit student grades for one or more classes completed in the previous semester. The actor in this use case is the Professor.
Brief Description:This use case allows the registrar to maintain student information in the registration system. This includes adding, modifying, and deleting students from the system. The actor for this use case is the Registrar. A description of the logical view of the architecture. Describes the most important classes, their organization in service packages and subsystems, and the organization of these subsystems into layers. Also describes the most important use-case realizations, for example, the dynamic aspects of the architecture. Class diagrams may be included to illustrate the relationships between architecturally significant classes, subsystems, packages and layers. The logical view of the course registration system is comprised of the 3 main packages: User Interface, Business Services, and Business Objects. The User Interface Package contains classes for each of the forms that the actors use to communicate with the System. Boundary classes exist to support login, maintaining of schedules, maintaining of professor info, selecting courses, submitting grades, maintaining student info, closing registration, and viewing report cards. The Business Services Package contains control classes for interfacing with the finance system, controlling student registration, and managing the student evaluation. The Business Objects Package includes entity classes for the university artifacts (i.e. course offering, schedule) and boundary classes for the interface with the Course Catalog System.
layer This user interface layer has all the boundary classes that represent the application screens that the user sees. This layer depends upon the Process Objects layer; that straddles the separation of the client from mid-tier. layer The Business Services process layer has all the controller classes that represent the use case managers that drive the application behavior. This layer represents the client-to-mid-tier border. The Business Services layer depends upon the Process Objects layer; that straddles the separation of the client from mid-tier. layer The Business Objects layer has all the entity classes that represent the "things" in the domain of the application. These reside on the server and use the service classes to assist in their responsibilities. layer The system classes provide a buffer between our object-oriented system and the functional behavior supported by the lower level system libraries. The system layer includes all classes to support secure access to the course registration system and its data. layer The Middleware layer supports access to Relational DBMS and OODBMS. The java package includes classes to support interfaces with remote objects, multiple threads of execution, and runnable code. The Base Reuse package includes classes to support list functions and patterns. A description of the process view of the architecture. Describes the tasks (processes and threads) involved in the system's execution, their interactions and configurations. Also describes the allocation of objects and classes to tasks. The Process Model illustrates the course registration classes organized as executable processes. Processes exist to support student registration, professor functions, registration closing, and access to the external Finance System and Course Catalog System. Diagram Name: Processes This process manages access to the legacy Course Catalog System. It can be shared by multiple users registering for courses. This allows for a cache of recently retrieved courses and offerings to improve performance. The separate threads within the CourseCatalog process, CourseCache and OfferingCache are used to asynchronously retrieve items from the legacy system. Analysis Mechanisms: - Legacy Interface Requirements Traceability: - Design Constraints: The system shall integrate with existing legacy system (course catalog database).
The unabbridged catalog of all courses and course offerings offered by the university including those from previous semesters. This class acts as an adapter (see the Gamma pattern). It works to makes sure the CourseCatalogSystem can be accessed through the ICourseCatalog interface to the subsystem.
There is one instance of this process for each student that is currently registering for courses.
This supports the use case allowing a student to register for courses in the current semester. The student can also modify or delete course selections if changes are made within the add/drop period at the beginning of the semester. Analysis Mechanisms: - Distribution
Manages the student functionality, including user interface processing and coordination with the business processes. There is one instance of this process for each student that is currently registering for courses.
Controls the interface of the Student application. Controls the family of forms that the Student uses.
This process communicates with the external Finance (Billing) System to initiate student billing.
The Close Registration process is initiated at the end of the registration time period. This process communicates with the process controlling access to the Finance System.
The Finance System supports the submitting of student bills for the courses registered for by the student for the current semester. Analysis Mechanisms: - Legacy Interface
The Close Registration Controller controls access to the Finance System. Analysis Mechanisms: - Distribution
Diagram Name: Process to Design Elements Manages the student functionality, including user interface processing and coordination with the business processes. There is one instance of this process for each student that is currently registering for courses.
Controls the interface of the Student application. Controls the family of forms that the Student uses.
There is one instance of this process for each student that is currently registering for courses.
This supports the use case allowing a student to register for courses in the current semester. The student can also modify or delete course selections if changes are made within the add/drop period at the beginning of the semester. Analysis Mechanisms: - Distribution
The Close Registration process is initiated at the end of the registration time period. This process communicates with the process controlling access to the Finance System.
The Close Registration Controller controls access to the Finance System. Analysis Mechanisms: - Distribution
This process communicates with the external Finance (Billing) System to initiate student billing.
The Finance System supports the submitting of student bills for the courses registered for by the student for the current semester. Analysis Mechanisms: - Legacy Interface
A class offered by the university. Analysis Mechanisms: - Persistency - Legacy Interface The unabbridged catalog of all courses and course offerings offered by the university including those from previous semesters. This class acts as an adapter (see the Gamma pattern). It works to makes sure the CourseCatalogSystem can be accessed through the ICourseCatalog interface to the subsystem. The Course Cache thread is used to asynchronously retrieve items from the legacy Course Catalog System. This process manages access to the legacy Course Catalog System. It can be shared by multiple users registering for courses. This allows for a cache of recently retrieved courses and offerings to improve performance. The separate threads within the CourseCatalog process, CourseCache and OfferingCache are used to asynchronously retrieve items from the legacy system. Analysis Mechanisms: - Legacy Interface Requirements Traceability: - Design Constraints: The system shall integrate with existing legacy system (course catalog database). The OfferingCashe thread is used to asynchronously retrieve items from the legacy Course Catalog System.
A specific offering for a course, including days of the week and times. Analysis Mechanisms: - Persistency - Legacy Interface Diagram Name: Main This process communicates with the external Finance (Billing) System to initiate student billing.
The Close Registration process is initiated at the end of the registration time period. This process communicates with the process controlling access to the Finance System.
The Finance System supports the submitting of student bills for the courses registered for by the student for the current semester. Analysis Mechanisms: - Legacy Interface
The Close Registration Controller controls access to the Finance System. Analysis Mechanisms: - Distribution
There is one instance of this process for each student that is currently registering for courses.
This supports the use case allowing a student to register for courses in the current semester. The student can also modify or delete course selections if changes are made within the add/drop period at the beginning of the semester. Analysis Mechanisms: - Distribution
Manages the student functionality, including user interface processing and coordination with the business processes. There is one instance of this process for each student that is currently registering for courses.
Controls the interface of the Student application. Controls the family of forms that the Student uses.
This process manages access to the legacy Course Catalog System. It can be shared by multiple users registering for courses. This allows for a cache of recently retrieved courses and offerings to improve performance. The separate threads within the CourseCatalog process, CourseCache and OfferingCache are used to asynchronously retrieve items from the legacy system. Analysis Mechanisms: - Legacy Interface Requirements Traceability: - Design Constraints: The system shall integrate with existing legacy system (course catalog database).
The unabbridged catalog of all courses and course offerings offered by the university including those from previous semesters. This class acts as an adapter (see the Gamma pattern). It works to makes sure the CourseCatalogSystem can be accessed through the ICourseCatalog interface to the subsystem.
Diagram Name: Process Model to Design Model Dependencies
Diagram Name: Processes to the Implementation Controls the interface of the Professor application. Controls the family of forms that the Professor uses. Manages the student functionality, including user interface processing and coordination with the business processes. There is one instance of this process for each student that is currently registering for courses. There is one instance of this process for each student that is currently registering for courses. The Close Registration process is initiated at the end of the registration time period. This process communicates with the process controlling access to the Finance System. This process communicates with the external Finance (Billing) System to initiate student billing. * The Remote interface serves to identify all remote objects. Any object that is a remote object must directly or indirectly implement this interface. Only those methods specified in a remote interface are available remotely. * Implementation classes can implement any number of remote interfaces and can extend other remote implementation classes. * The Runnable interface should be implemented by any class whose instances are intended to be executed by a thread. The class must define a method of no arguments called run. * This interface is designed to provide a common protocol for objects that wish to execute code while they are active. For example, Runnable is implemented by class Thread. * Being active simply means that a thread has been started and has not yet been stopped. The OfferingCashe thread is used to asynchronously retrieve items from the legacy Course Catalog System. This process manages access to the legacy Course Catalog System. It can be shared by multiple users registering for courses. This allows for a cache of recently retrieved courses and offerings to improve performance. The separate threads within the CourseCatalog process, CourseCache and OfferingCache are used to asynchronously retrieve items from the legacy system. Analysis Mechanisms: - Legacy Interface Requirements Traceability: - Design Constraints: The system shall integrate with existing legacy system (course catalog database). * A thread is a thread of execution in a program. The Java Virtual Machine allows an application to have multiple threads of execution running concurrently. * Every thread has a priority. Threads with higher priority are executed in preference to threads with lower priority. Each thread may or may not also be marked as a daemon. When code running in some thread creates a new Thread object, the new thread has its priority initially set equal to the priority of the creating thread, and is a daemon thread if and only if the creating thread is a daemon.
A description of the deployment view of the architecture Describes the various physical nodes for the most typical platform configurations. Also describes the allocation of tasks (from the Process View) to the physical nodes. This section is organized by physical network configuration; each such configuration is illustrated by a deployment diagram, followed by a mapping of processes to each processor. Diagram Name: Deployment View Students register for courses using external desktop PCs which are connected to the College Server via internet dial up. Students register for courses via local Desktop PCs that are connected directly to the College Server via LAN. These local PCs are also used by professors to select course and submit student grades. The Registrar uses these local PCs to maintain student and professor information. The Registration Server is the main campus UNIX Server. All faculty and students have access to the Server through the campus LAN. The Course Catalog System is a legacy system that contains the complete course catalog. Access to it is available via the College Server and LAN. The Billing System (also called the Finance System) is a legacy system that generates the student bills each semester.
|
|
Rational Unified
Process |